# Генерация элементов бэклога
## Описание
Бэклог – это упорядоченный список задач, которые поступают на вход команде разработки. Менеджер отвечает за его наполнение обоснованными и ценными Product Backlog Items (PBI). Для каждого из запланированных улучшений он должен отвечать на два вопроса:
- Почему это улучшение ценно?
- Удобно ли это улучшение для пользователя?

Для генерации новых элементов бэклога менеджер может использовать следующие источники:
- Аналитика продукта
- Интервью с пользователями
- Результаты UX-исследований
- Анализ конкурентов
- Анализ рынка и трендов
- Стратегия бизнеса и продукта

В рамках этой ветки рассматривается только работа с улучшениями продукта. Задачи, связанные с техническим долгом или инженерной культурой, являются ответственностью другой роли – Technical Lead.

## Почему ветка важна?
Для компании:
- В разработку уходят только идеи с подтверждённой гипотезой ценности.
- Любой желающий может ознакомиться с планами команды, изучив её бэклог.
- Вопросам удобства использования уделяется внимание до старта разработки задачи.

Для менеджера:
- Есть единый источник правды, определяющий загрузку и приоритеты команды разработки.
- Для каждого из улучшений, которое команда берет в разработку, можно чётко ответить, почему его надо делать.

Для команды:
- Возможность планировать следующие итерации разработки без стресса, если на входе у них есть готовый бэклог.

## Что будет, если её не делать?
- В разработку будут поступать задачи, не прошедшие проверку ценности или удобства.
    - Фичи не принесут ожидаемой пользы для продукта и бизнеса.
- Команда будет хаотично прыгать между задачами из разных областей продукта.
    - Не будет системного продвижения к поставленным продуктовым целям.
- Любой стейкхолдер сможет свободно проталкивать свои задачи в разработку, исходя из принципа "кто громче кричит".

## На кого может быть делегирована?
- Product Owner
- Тимлид ниже уровнем
- Разработчик, ответственный за конкретную фичу

## Примеры поведения
### Примеры плохого поведения
- Бэклога нет.
- В бэклоге появляются задачи, ценность которых не подтверждена ничем, кроме экспертного мнения тимлида или заказчика.
- Удобство новых фич проверяется только на конечных пользователях после релиза.
- PBI описаны хаотично или вообще не имеют описания.
- Задачи в бэклоге не связаны совсем, либо связаны лишь косвенно с целями команды.

### Примеры хорошего поведения
- У команды есть продуктовый бэклог, который доступен на просмотр любому желающему.
- Каждый PBI описан по стандартному шаблону. Можно изучить изначальную гипотезу, её валидацию, посмотреть definition of done.
- Все члены команды знают, что за фича разрабатывается, почему она ценна, какая польза от неё ожидается на выходе.
- Бэклог прозрачен для стейкхолдеров.

## Способы прокачки
### Практика
Пройди отличный онлайн-курс управления продуктом на основе данных [Go Practice](https://simulator.gopractice.ru/). Он реализован в виде симулятора – всю получаемую теорию ты сразу же применяешь в специальной песочнице на практике.

## Консультации
- [Telegram-чат TL Bootcamp](https://tlinks.run/tlbootcamp)
- [Продуктовый Telegram-чат No Flame no Game](https://t.me/joinchat/BrfI2UHjvA2HbQNSW4Irog)

## Теория
### Статьи
- [What is the Product Backlog in Product Management and How to Maintain It](https://hygger.io/blog/what-is-the-product-backlog-in-product-management/)
- [How to Fill Up Your Product Backlog](https://hygger.io/blog/how-to-fill-product-backlog/)
- [Как формировать бэклог и приоритезировать его](https://medium.com/how-i-met-your-product/%D0%BA%D0%B0%D0%BA-%D1%84%D0%BE%D1%80%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1%8C-%D0%B1%D1%8D%D0%BA%D0%BB%D0%BE%D0%B3-%D0%B8-%D0%BF%D1%80%D0%B8%D0%BE%D1%80%D0%B8%D1%82%D0%B5%D0%B7%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1%8C-%D0%B5%D0%B3%D0%BE-8f96d6e420d0)

### Книги
- [Intercom on Product Management](https://www.intercom.com/books/product-management)
- [Inspired: How to Create Products Customers Love, Marty Cagan](https://www.amazon.co.uk/Inspired-Create-Products-Customers-Love/dp/0981690408)
